Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9610/000152_owner-urn-ietf _Thu Oct 31 15:53:05 1996.msg

Internet Message Format | 1997-02-19 | 5KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA19791 for urn-ietf-out; Thu, 31 Oct 1996 15:53:05 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA19786 for <[e-mail]>; Thu, 31 Oct 1996 15:53:03 -0500
Received: from loki.fsc.fujitsu.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA28793  (mail destined for [e-mail]); Thu, 31 Oct 96 15:52:58 -0500
Received: from ishtar.fsc.fujitsu.com (ishtar [192.240.3.45]) by loki.fsc.fujitsu.com (8.7.5/8.6.11) with ESMTP id MAA23504; Thu, 31 Oct 1996 12:51:25 -0800 (PST)
Received: (from tallen@localhost) by ishtar.fsc.fujitsu.com (8.7.5/8.6.11) id MAA10123; Thu, 31 Oct 1996 12:51:48 -0800 (PST)
Date: Thu, 31 Oct 1996 12:51:48 -0800 (PST)
From: Terry Allen <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Names and Locations (was [URN] some comments)
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
Reply-To: Terry Allen <[e-mail]>
Errors-To: [e-mail]

|  > > You made the curious statement that URNs identify resources while URLs
|  > > identify locations.  I'm not sure whether that was a slip, but to my
|  > > mind, a URL *IS* a location that identifies a resource.  Now you also
|  > URLs identify a particular location for a resource.
| OK, what is a location?  Is it the bits on the disk that "has" the
| resouce?  (The disk might be shared by many servers, so the resource
| has a different "location" for each server.) Is it the server running
| at a particular IP address and port, that may share many disks with
| other servers?  (The server may be a virtual server that runs on many
| machines, and the particular IP address is irrelevant.)  Is it the
| domain name of the server, together with the path within the server?
| That's getting closer to the abstraction that URLs provide.  Is the
| location, in fact, the URL itself?

No, the URL is neither the location nor the resource, but the
name of a location, or a name of a location that may be resolved
on the fly.  The location is not the resource; the name of the
location is not the name of the resource.

| Consider caches.  The resolution of a URL via a cache proxy may find
| the resource in the cache rather than in some remote server.  What is
| "the location" of the resource in that case?

What is "the resource"?  Any copy of what you got back from resolution?
then its location is both in the cache and on the remote server.
Is it "the copy I got back from resolution"?  then its location
is in the cache.

| Here is an example of how what is thought of as a location really
| turns out to *be* a name (as in persistent location).  Take a normal
| http URL such as http://www.ncsa.uiuc.edu/.  Instead of using normal
| HTTP to resolve the URL, or to look it up in a cache, let's set up a
| NAPTR-based "http" naming authority.  Under that branch of the name
| space, we could ask the appropriate DNS server to look up
| 'www.ncsa.uiuc.edu' to find out where a server is currently located
| and what "resolution protocols" are currently supported.

That is a coincidence of naming:  you made the name of the resource
(qua URN) be the same as the name of its location.  But
   urn:http://www.ncsa.uiuc.edu/
and
   url:http://www.ncsa.uiuc.edu/
name two different things.

| We don't need to create a new kind of identifier to make a URL into a
| persistent location.

Which is not what you did in the example just given.  You created
a new name space and rules for using it that by design produce
a name that looks like a URL which, when resolved, will give the
same result.

| To summarize, both URLs and URNs have the following abstract
| resolution process in common:
| 1. Do some client-specific processing of the URI - maybe end there.
| 2. Look at the scheme name of the URI.  If it says "URN:" drop it and repeat.

No, you have to branch into your "find URN" subprocess.

| 3. Look up the scheme in local table to find out what process should

The local table will be different for URLs and URNs, will it not?

|    be invoked.  E.g. news URIs may use NNTP, http URIs may use HTTP,
|    cid URIs may use NAPTR-protocol.
| 4. Invoke the process identified by step 3.
| 5. If error results, exit.
| 6. If redirected to another URI, repeat whole process with that URI.
|
| An alternative to steps 2 and 3 would use more than just the scheme
| name to determine what process to invoke.  There are several other
| varients possible in the whole process, and each client or each user
| might do things differently.
|
| I hope I've made my postion very clear regarding names, locations, and
| the resolution process.

That you see no difference between objects and their locations?


(apologies for the "ig" subject line in a previous post)

    Terry Allen    Fujitsu Software Corp.    [e-mail]
"In going on with these experiments, how many pretty systems do we build,
 which we soon find outselves obliged to destroy?" - Benjamin Franklin
  A Davenport Group Sponsor:  http://www.ora.com/davenport/index.html